Software developers can use various tools to analyze software, such as to identify programming defects. Tools can generally be classified based on whether they perform a “static” analysis on software source code or a “dynamic” analysis on executing software object code. Examples of common programming defects that analysis tools can identify include using memory before it has been allocated or after it has been unallocated, using file handles before a file has been opened or after it has been closed, assigning incorrect value types to variables, and so forth. Various tools are available that perform static analyses by analyzing procedures in software that is written using a standard imperative programming language, such as C, C++, BASIC, Pascal, and Fortran. Software developers can use imperative programming languages to write software that executes in a sequential style, such as software code that flows from one procedure to another. Even when this software has parallel execution paths, such as when the software employs multiple threads, the tools can analyze the execution paths sequentially. Tools that analyze sequentially designed software generally cannot identify defects based on data in a heap because the heap is constructed when the software executes. The heap is an area of memory that executing software can use, such as to store values assigned to variables, class instances, and so forth. However, even dynamic analysis of software cannot identify some types of errors despite being able to analyze the heap. As an example, dynamic analysis cannot identify various defects that occur in software that has asynchronously communicating “layers” or components (“asynchronous components”).
When two asynchronous components communicate, a requesting component makes an asynchronous request to a responding component. The responding component can perform a portion of the requested operation and return execution to the requesting component, such as with a status indicating that the operation is pending. One or both components may store various attributes in a heap, such as a count of the number of requests that are pending, the status of each request, and so forth. The responding component may then complete the remainder portion of the requested operation later. When the operation completes, the responding component may invoke a method provided by the requesting component to indicate that the operation is complete.
Software developers generally use an event-driven programming style when designing asynchronous layers. Event-driven programming can provide superior performance as compared to other styles of programming that can be used to design asynchronous layers because synchronous communications between components can be reduced by registering events that other components can handle asynchronously. As an example, a network driver may employ event-driven programming when sending or receiving messages. An application that communicates with a server may invoke a send_message method of the network driver to send a message to the server. The send_message method may determine whether a network interface card is busy sending or receiving other messages. If it is not busy, the send_message method may send the message and return a success indication to the application. However, if the network interface card is busy, the network driver may queue the message for sending later and return a status indication that the message has not yet been sent. An asynchronous component of the network driver may perform the send_message method when that method is invoked by an application or the operating system. Another asynchronous component of the network driver can interact with the network interface card and send messages that are waiting in the queue. As an example, after the asynchronous component that interacts with the network interface card determines that no messages are being sent or received, it can send a message waiting in the queue. Before sending the message, this asynchronous component may need to determine that the message is ready to send. Because several places in the code may modify messages waiting in the queue, a static analysis tool may be unable to determine whether the message is sent after it is ready to send. Thus, software code that is implemented using event-driven programming styles or has asynchronous components can be difficult to analyze because it is nonsequential and asynchronous, and can maintain state information in a heap.